docs: tushare endpoint permission/rate-limit probe + capability registry - #28
Merged
Merged
Conversation
SDK-authoritative probe (python tushare 1.4.29 + external token file) of 28 endpoints, classifying each into authorized / empty_authorized / rate_limited / no_permission. MCP single-shot probing only proves permission, not batch viability, so the SDK result is the source of truth. Key findings (2026-06-13): - core P0..P4-2 endpoints all authorized + proven batch-viable in real runs; - value/low-vol & special candidate sources (stk_factor_pro, cyq_*, moneyflow*, limit_list_d, top_list, block_trade, margin_detail, stk_surv) authorized but per-batch rate limit NOT stress-tested; - stk_mins and hm_detail are authorized but throttled to 1 call/hour -> callable but NOT batch-viable (minute-level ETL needs a separately purchased tier); - stk_auction_o / stk_auction_c are 40203 no_permission. Deliverables (no token, no account points anywhere): - docs/data/tushare_permissions.md: audit table (permission vs rate-limit vs batch viability vs PIT timing) + explicit post-close look-ahead warnings for cyq_*/moneyflow*/limit_list_d candidates. - data/feed/tushare_capabilities.py: token-free, importable capability registry (metadata + usage intent + dated observed_status); explicitly NOT a runtime permission gate. - artifacts/permissions/tushare_probe_20260613.json: raw probe output (gitignored, token-free; errors scrubbed).
…e 3/3) Same-day re-probe of stk_mins via SDK: 3/3 small calls succeeded in ~12s, so the earlier "频率超限(1次/小时)" throttle is gone. Update the capability registry (observed_status rate_limited -> authorized) and the permissions doc (move stk_mins out of the not-batch-viable group; minute-level data is now feasible at the data layer, exact per-minute ceiling still unstress-tested). hm_detail was NOT re-checked and keeps its 1/hour finding. Gitignored probe artifact updated in place (token-free).
The status-enum note still lumped stk_mins with hm_detail as both stuck at 1 call/hour. Clarify that stk_mins was re-probed the same day (3/3, cap lifted) while hm_detail keeps its 1/hour finding and was not re-checked — consistent with the tables and conclusion below.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
SDK-authoritative probe of 28 Tushare endpoints, persisted per project conventions: a reviewable audit doc, a token-free machine-readable capability registry, and a gitignored raw-probe artifact. No new factor, no backtest-logic change, no token in the repo.
MCP single-shot probing only proves permission, not batch viability (rate limit), so the Python SDK result is the source of truth.
Findings (2026-06-13)
stk_mins: first probe hit频率超限(1次/小时); a same-day re-probe was 3/3 in ~12s — the 1/hour cap is lifted, so minute data is now feasible at the data layer (exact per-minute ceiling still unstress-tested). Registry/doc updated accordingly.hm_detail: authorized but throttled to 1 call/hour (not re-checked this round) → callable but not batch-viable.stk_auction_o/stk_auction_c:40203no_permission (call-auction family needs a separate tier).Files
docs/data/tushare_permissions.md— audit table: permission vs rate-limit vs batch viability vs PIT timing, plus explicit post-close look-ahead warnings for cyq_/moneyflow/limit_list_d candidates.data/feed/tushare_capabilities.py— token-free, importable capability registry (metadata + usage intent + datedobserved_status); explicitly NOT a runtime permission gate.artifacts/permissions/tushare_probe_20260613.json— raw probe output (gitignored, token-free, errors scrubbed).PIT discipline
Candidate sources cyq_/moneyflow/limit_list_d/top_list/hm_detail/block_trade/margin_detail are post-close data — T-day values must never feed T-day close selection (look-ahead); usable only at T+1. Any candidate entering the P3 matrix still follows the EXPLORATORY + independent-sample discipline.
Test plan
py_compile data/feed/tushare_capabilities.pyOK; module imports, 28/28 endpoints, no token.pytest tests -q— all pass (428); docs/registry are additive, no code/test behavior change.ruff check .clean.artifacts/permissions/confirmed gitignored.